Quality of Service (QoS) is the measure of service quality provided to a subscriber. In contrast to traditional data traffic, multimedia streams such as those used in IP telephony or video conferencing may be extremely bandwidth and delay sensitive, imposing unique QoS demands on the underlying networks that carry them. Unfortunately, Internet Protocol (IP), with a connectionless, “best-effort” delivery model, does not guarantee delivery of data packets in order, in a timely manner, or at all. Consequently, as the Internet evolves from a “best-effort” network to one supporting multimedia communication, it becomes important to be able to signal QoS requirements of applications to the Internet. A number of different scenarios and requirements for QoS signaling are suggested by the Internet Engineering Task Force (IETF) NSIS working group. These scenarios cover a broad scope including, among others:
Terminal Mobility:
The QoS signaling must cope with handoff of end terminal, possibly between network domains with heterogeneous QoS technologies.
Cellular Networks:
The QoS signaling must be able to integrate with cellular access technologies such as, for example, a Universal Mobile Telecommunications System (UMTS) network.
Qos Reservation from Access to Core Network:
The signaling should allow for aggregate QoS provision and negotiation between access and core networks.
Administrative Boundaries:
It should be possible to signal QoS over the administrative boundaries.
Due to the conflicting requirements imposed by these different usage environments (for instance, there is a possible conflict between a lightweight signaling mechanism required over the wireless link and a reliable and robust mechanism required to provision QoS for aggregate traffic in the core network), it is unlikely that the same QoS signaling protocol can be used in all environments. Consequently, it is desirable to have a “QoS signaling toolkit”, wherein each tool is optimized for a particular situation such as the following:
Edge QoS Signaling:
This signaling covers signaling between a mobile node (MN) and its access router (AR) as well as horizontal signaling between ARs. The wireless link to the MN induces the requirement of bandwidth economy on the signaling between the MN and the AR. Signaling between ARs imposes requirements similar to those of a context transfer framework.
Data Path QoS Signaling: This signaling covers the signaling along the data path to establish, tear down or modify QoS. The desire for a seamless handoff in a mobile environment induces the requirement of speed on the signaling used to re-establish or maintain QoS upon handoff Further, since there may likely be frequent handoffs in future mobile networks, it would be advantageous to keep the overhead of handoff-induced QoS signaling at a minimal level.
Generic QoS Signaling: This signaling uses a set of rules for increased reliability, robustness or redundancy when there are less bandwidth constraints or time constraints.
The present invention relates primarily to the Data Path QoS Signaling. Referring to FIG. 1, an example system is shown for QoS and mobile IP handoff in a network 100 having one or more mobile nodes (MN) 105, two or more access routers (AC) 110, 112, two or more QoS controllers (QC) 115, 117, 118 and one or more correspondent nodes (CN) 120. Respective wired or wireless links/data paths (shown by dotted or solid lines) connect the various network components. In this example architecture the QoS signaling tools optimized for mobile IP handoff must cover the horizontal signaling which occurs between AR 110 and AR 112 to begin handoff as well as the vertical signaling along the packet data path (e.g. between MN 105 (or AR 112 on behalf of MN 105) and CN 120), both of which are triggered by the handoff of mobile node (MN) 105, (for example as MN 105 changes connection points from AR 110 at connection A to AR 112 at connection B). The horizontal signaling between ARs 110 and 112 occurs during initiation of the handoff and the vertical signaling between MN 105 (or by AR 112 on behalf of MN 105) and CN 120 typically occurs after the horizontal signaling.
The QoS signaling follows the data path from mobile node MN 105 to correspondent node CN 120 through a set of QoS Controllers (QCs) 115, 116, 117, 118 (depending on the path needed). The QCs could be all the routers on the path, or a subset of routers that effectively control the QoS over the whole path. Among others, QCs 115, 116, 117, 118 perform functions such as multi-field packet classification, admission control, etc. This is similar to the architecture considered in IETF RFC 2998—Y. Bernet, et al., “A Framework for Integrated Services Operation over DiffServ Networks,” November 2000. As used herein, the terms QC (or controller) and router may be used interchangeably. However, every router on a path is not necessarily a QC.
The existing IETF protocol to implement QoS signaling is Resource Reservation Protocol (RSVP). RSVP is an IETF standard designed to support resource (for example, bandwidth) reservations through networks of varying topologies and media. Through RSVP, a user's QoS requests are propagated to all routers along the data path, allowing the network to reconfigure itself (at all network levels) to meet the desired level of service. The RSVP protocol engages network resources by establishing flows throughout the network. A flow is a network path associated with one or more senders, one or more receivers, and a certain QoS. For example, a sending host wishing to send data that requires a certain QoS will transmit, via an RSVP-enabled Winsock Service Provider, a “path” message toward the intended recipients. These path messages, which describe the bandwidth requirements and relevant parameters of the data to be sent, are propagated to all intermediate routers along the path.
A receiving host, interested in this particular data, will confirm the flow (and network path) by sending “reserve” messages through the network, describing the bandwidth characteristics of data it wishes to receive from the sender. As these reserve messages propagate back toward the sender, intermediate routers, based on the bandwidth capacity, decide whether or not to accept the proposed reservation and commit resources. If an affirmative decision is made, the resources are committed and reserve messages are propagated to the next hop on the path from the source to destination.
However, RSVP has serious performance drawbacks in mobile IP environments where handoffs happen in the middle of an ongoing session, for example, when the end-to-end path of packets changes or when the care-of address changes after handoff. The OPWA (One Pass with Advertisement) model used in RSVP causes a latency (or delay) of the time for about one round trip between the MN and the CN before the QoS can be established along the new data path. This is because for OPWA, the packets using the new care-of address may get default QoS treatment until they have completed the round trip between the MN and CN. Additionally, RSVP does not have any security mechanisms for protecting against fraudulent QoS set up and tear down in the mobile IP environment.
Furthermore, it is would be beneficial to have QoS signaling that is secure and can be authenticated in order to reduce the susceptibility of QoS to spoofing attacks. A spoofing attack is a message with a header containing a source address that does not reflect the legitimate source of the message. Spoofing attacks may compromise the integrity of establishing and maintaining QoS in mobile IP and should be eliminated if possible.
Consequently, it would be desirable to provide improved methods, systems and protocol for QoS signaling in mobile IP handoffs